home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-tuba-clnp-03.txt < prev    next >
Text File  |  1993-07-08  |  50KB  |  1,520 lines
  1.  
  2. IETF                               Page 1
  3. July 2, 1993             CLNP for TUBA             Internet Draft
  4.                                               Expire: February 94
  5.  
  6.  
  7.               Use of ISO CLNP in TUBA Environments
  8.  
  9.  
  10.               David M. Piscitello
  11.                     Bellcore
  12.                   dave@sabre.bellcore.com
  13.  
  14.  
  15.                        Status of this Memo
  16.  
  17. This document is an Internet Draft.  Internet Drafts are working
  18. documents of the Internet Engineering Task Force (IETF), its
  19. Areas, and its Working Groups. Note that other groups may also
  20. distribute working documents as Internet Drafts.
  21.  
  22. Internet Drafts are draft documents valid for a maximum of six
  23. months. Internet Drafts may be updated, replaced, or obsoleted by
  24. other documents at any time.  It is not appropriate to use
  25. Internet Drafts as reference material or to cite them other than
  26. as a "working draft" or "work in progress."
  27.  
  28. Please check the Internet Draft abstract listing contained in the
  29. IETF Shadow Directories (cd internet-drafts) to learn the current
  30. status of this or any other Internet Draft.
  31.  
  32. This Internet-Draft specifies a profile of the ISO/IEC 8473
  33. Connectionless-mode Network Layer Protocol (CLNP, [1]) for use in
  34. conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA,
  35. [2]).  This draft document will be submitted to the RFC editor as
  36. a protocol specification. Distribution of this memo is unlimited.
  37. Please send comments to dave@eve.bellcore.com.
  38.  
  39.  
  40.                             Abstract
  41.  
  42. This document describes the use of CLNP to provide the lower-
  43. level service expected by Transmission Control Protocol (TCP,
  44. [3]) and User Datagram Protocol (UDP, [4]). CLNP provides
  45. essentially the same datagram service as Internet Protocol (IP,
  46. [5]), but offers a means of conveying bigger network addresses
  47. (with additional structure, to aid routing).
  48.  
  49. While the protocols offer nearly the same services, IP and CLNP
  50. are not identical. This document describes a means of preserving
  51. the semantics of IP information that is absent from CLNP while
  52. preserving consistency between the use of CLNP in Internet and
  53. OSI environments. This maximizes the use of already-deployed CLNP
  54. implementations.
  55.  
  56.  
  57.                          Acknowledgments
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69. IETF                               Page 2
  70. Internet Draft            CLNP for TUBA              July 2, 1993
  71.  
  72.  
  73. Many thanks to Ross Callon (Wellfleet Communications), John
  74. Curran (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian
  75. Carpenter (CERN), Keith Sklower (Cal Berkeley), Dino Farinacci
  76. and Dave Katz (Cisco Systems) and David Oran (DEC) for their
  77. assistance in composing this text.
  78.  
  79.  
  80.                            Conventions
  81.  
  82. The following language conventions are used in the items of
  83. specification in this document:
  84.  
  85.    o+ Must, Shall, or Mandatory -- the item is an absolute
  86.      requirement of the specification.
  87.  
  88.    o+ Should or Recommended -- the item should generally be
  89.      followed for all but exceptional circumstances.
  90.  
  91.    o+ May or Optional -- the item is truly optional and may be
  92.      followed or ignored according to the needs of the
  93.      implementor.
  94.  
  95.  
  96. 1.  Terminology
  97.  
  98. To the extent possible, this document is written in the language
  99. of the Internet. For example, packet is used rather than
  100. "protocol data unit", and "fragment" is used rather than
  101. "segment".  There are some terms that carry over from OSI; these
  102. are, for the most part, used so that cross-reference between this
  103. document and RFC 994 [6] or ISO/IEC 8473 is not entirely painful.
  104. OSI acronyms are for the most part avoided.
  105.  
  106.  
  107. 2.  Introduction
  108.  
  109. The goal of this specification is to allow compatible and
  110. interoperable implementations to encapsulate TCP and UDP packets
  111. in CLNP data units. In a sense, it is more of a "hosts
  112. requirements" document for the network layer of TUBA
  113. implementations than a protocol specification. It is assumed that
  114. readers are familiar with RFC 791, RFC 792 [7], RFC 1122 [8],
  115. and, to a lesser extent, RFC 994 and ISO/IEC 8473.  This document
  116. is compatible with (although more restrictive than) ISO/IEC 8473;
  117. specifically, the order, semantics, and processing of CLNP header
  118. fields is consistent between this and ISO/IEC 8473.
  119.  
  120. [Editor's Note: RFC 994 contains the Draft International Standard
  121. version of ISO CLNP, in ASCII text. This is not the final version
  122. of the ISO/IEC protocol specification; however, it should provide
  123. sufficient background for the purpose of understanding the
  124. relationship of CLNP to IP, and the means whereby IP information
  125. is to be encoded in CLNP header fields. Postscript versions of
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135. IETF                               Page 3
  136. July 2, 1993             CLNP for TUBA             Internet Draft
  137.  
  138.  
  139. ISO CLNP and associated routing protocols are available via
  140. anonymous FTP from merit.edu, and may be found in the directory
  141. /pub/ISO/IEC.
  142.  
  143.  
  144. 3.  Overview of CLNP
  145.  
  146. ISO CLNP is a datagram network protocol. It provides
  147. fundamentally the same underlying service to a transport layer as
  148. IP. CLNP provides essentially the same maximum datagram size, and
  149. for those circumstances where datagrams may need to traverse a
  150. network whose maximum packet size is smaller than the size of the
  151. datagram, CLNP provides mechanisms for fragmentation (data unit
  152. identification, fragment/total length and offset). Like IP, a
  153. checksum computed on the CLNP header provides a verification that
  154. the information used in processing the CLNP datagram has been
  155. transmitted correctly, and a lifetime control mechanism ("Time to
  156. Live") imposes a limit on the amount of time a datagram is
  157. allowed to remain in the internet system. As is the case in IP, a
  158. set of options provides control functions needed or useful in
  159. some situations but unnecessary for the most common
  160. communications.
  161.  
  162. Table 1 provides a high-level comparison of CLNP to IP:
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201. IETF                               Page 4
  202. Internet Draft            CLNP for TUBA              July 2, 1993
  203.  
  204.  
  205. Function                | ISO CLNP              | DOD IP
  206. ------------------------|-----------------------|-----------------------
  207. Header Length           | indicated in octets   | in 32-bit words
  208. Version Identifier      | 1 octet               | 4 bits
  209. Lifetime (Time to live) | 500 msec units        | 1 sec units
  210. Flags                   | Fragmentation allowed,| Don't Fragment,
  211.                         | More Fragments        | More Fragments,
  212.                         | Suppress Error Reports| <not defined>
  213. Packet Type             | 5 bits                | <not defined>
  214. Fragment Length         | 16 bits, in octets    | 16 bits, in octets
  215. Header Checksum         | 16-bit (Fletcher)     | 16-bit
  216. Total Length            | 16 bits, in octets    | <not defined>
  217. Addressing              | Variable length       | 32-bit fixed
  218. Data Unit Identifier    | 16 bits               | 16 bits
  219. Fragment offset         | 16 bits, in octets    | 13 bits, 8-octet units
  220. Higher Layer Protocol   | Selector in address   | PROTOcol (assigned #)
  221. Options                 | Security              | Security
  222.                         | Priority              | Precedence bits in TOS
  223.                         | Complete Source Route | Strict Source Route
  224.                         | Quality of Service    | Type of Service
  225.                         | Partial Source Route  | Loose Source Route
  226.                         | Record Route          | Record Route
  227.                         | Padding               | Padding
  228.                         | <defined herein>      | Timestamp
  229.  
  230.  
  231.  
  232.                 Table 1. Comparison of IP to CLNP
  233.  
  234. Note that the encoding of options differs between the two
  235. protocols, as do the means of higher level protocol
  236. identification. Note also that CLNP and IP differ in the way
  237. header and fragment lengths are represented, and that the
  238. granularity of lifetime control (time-to-live) is finer in CLNP.
  239. Some of these differences are not considered "issues", as CLNP
  240. provides flexibility in the way that certain options may be
  241. specified and encoded (this will facilitate the use and encoding
  242. of certain IP options without change in syntax); others, e.g.,
  243. higher level protocol identification and timestamp, must be
  244. accommodated in a transparent manner in this profile for correct
  245. operation of TCP and UDP, and continued interoperability with OSI
  246. implementations. Section 4 describes how header fields of CLNP
  247. must be populated to satisfy the needs of TCP and UDP.
  248.  
  249. Errors detected during the processing of a CLNP datagram may be
  250. reported using CLNP Error Reports. Implementations of CLNP for
  251. TUBA environments must be capable of processing Error Reports
  252. (this is consistent with the 1992 edition (2)  of the ISO/IEC
  253. 8473 standard).  Control messages (e.g., echo request/reply and
  254. redirect) are similarly handled in CLNP, i.e., identified as
  255. separate network layer packet types.  The relationship between
  256. CLNP Error and Control messages and Internet Control Message
  257. Protocol (ICMP, [7]), and issues relating to the handling of
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267. IETF                               Page 5
  268. July 2, 1993             CLNP for TUBA             Internet Draft
  269.  
  270.  
  271. these messages is described in Section 5.
  272.  
  273. The composition and processing of a TCP pseudo-header when CLNP
  274. is used to provide the lower-level service expected by TCP and
  275. UDP is described in Section 6.
  276.  
  277.  
  278.  
  279. 4.  Proposed Internet Header using CLNP
  280.  
  281. A summary of the contents of the CLNP header, as it is proposed
  282. for use in TUBA environments, is illustrated in Figure 4-1:
  283.  
  284.  
  285.     0                   1                   2                   3
  286.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  287.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  288.    |        ........Data Link Header........       | NLP ID        |
  289.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  290.    |Header Length  |     Version   | Lifetime (TTL)|Flags|  Type   |
  291.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  292.    |        Fragment Length        |           Checksum            |
  293.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  294.    | Dest Addr Len |               Destination Address...          |
  295.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  296.    |               ... Destination Address...                      |
  297.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.    |               ... Destination Address...                      |
  299.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  300.    |               ... Destination Address...                      |
  301.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302.    |               ... Destination Address...                      |
  303.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  304.    | PROTO field   | Src  Addr Len |  Source  Address...           |
  305.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  306.    |               ... Source Address...                           |
  307.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  308.    |               ... Source Address...                           |
  309.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  310.    |               ... Source Address...                           |
  311.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  312.    |               ... Source Address...                           |
  313.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  314.    |       ... Source Address      |   Reserved    | Data Unit...  |
  315.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  316.    | ...Identifier |         Fragment Offset       |Total Length.. |
  317.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  318.    | ... of Packet |             Options...                        |
  319.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  320.    |                                                               |
  321.    :                                                               :
  322.    |                    Options  (see Table 1)                     |
  323.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. IETF                               Page 6
  334. Internet Draft            CLNP for TUBA              July 2, 1993
  335.  
  336.  
  337.  
  338.           Note that each tick mark represents one bit position.
  339.  
  340.  
  341.  
  342.                         Figure 4-1. CLNP for TUBA
  343.  
  344. Note 1: For illustrative purposes, Figure 4-1 depicts Destination and
  345.         Source Addresses having a length of 19 octets, including the
  346.         PROTO/reserved field. In general, addresses can be variable
  347.         length, up to a maximum of 20 octets, including the
  348.         PROTO/reserved field.
  349.  
  350. Note 2: Due to differences in link layer protocols, it is not possible
  351.         to ensure that the packet starts on an even alignment.  Note,
  352.         however, that many link level protocols over which CLNP is operated
  353.         happen to use a odd length link (e.g., 802.2). (As profiled in
  354.         Figure 4-1, the rest of the CLNP packet is even-aligned.)
  355.  
  356.  
  357. The encoding of CLNP fields for use in TUBA environments is as
  358. follows.
  359.  
  360. 4.1  Network Layer Protocol Identification (NLP ID)
  361.  
  362. This one-octet field identifies this as the ISO/IEC 8473
  363. protocol; it must set to binary 1000 0001.
  364.  
  365. 4.2  Header Length Indication (Header Length)
  366.  
  367. Header Length is the length of the CLNP header in octets, and
  368. thus points to the beginning of the data. The value 255 is
  369. reserved. The header length is the same for all fragments of the
  370. same (original) CLNP packet.
  371.  
  372.  
  373.  
  374. 4.3  Version
  375.  
  376. This one-octet field identifies the version of the protocol; it
  377. must be set to a binary value 0000 0001.
  378.  
  379. 4.4  Lifetime (TTL)
  380.  
  381. Like the TTL field of IP, this field indicates the maximum time
  382. the datagram is allowed to remain in the internet system.  If
  383. this field contains the value zero, then the datagram must be
  384. destroyed; a host, however, must not send a datagram with a
  385. lifetime value of zero.  This field is modified in internet
  386. header processing.  The time is measured in units of 500
  387. milliseconds, but since every module that processes a datagram
  388. must decrease the TTL by at least one even if it process the
  389. datagram in less than 500 millisecond, the TTL must be thought of
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399. IETF                               Page 7
  400. July 2, 1993             CLNP for TUBA             Internet Draft
  401.  
  402.  
  403. only as an upper bound on the time a datagram may exist.  The
  404. intention is to cause undeliverable datagrams to be discarded,
  405. and to bound the maximum CLNP datagram lifetime. [Like IP, the
  406. colloquial usage of TTL in CLNP is as a coarse hop-count.]
  407.  
  408. 4.5  Flags
  409.  
  410. Three flags are defined. These occupy bits 0, 1, and 2 of the
  411. Flags/Type octet:
  412.  
  413.           0   1   2
  414.         +---+---+---+
  415.         | F | M | E |
  416.         | P | F | R |
  417.         +---+---+---+
  418.  
  419. The Fragmentation Permitted (FP) flag, when set to a value of one
  420. (1), is semantically equivalent to the "may fragment" value of
  421. the Don't Fragment field of IP; similarly, when set to zero (0),
  422. the Fragmentation Permitted flag is semantically equivalent to
  423. the "Don't Fragment" value of the Don't Fragment Flag of IP.
  424.  
  425. [Editor's Note: If the Fragmentation Permitted field is set to
  426. the value O, then the Data Unit Identifier, Fragment Offset, and
  427. Total Length fields are not present. This denotes a single
  428. fragment datagram. In such datagrams, the Fragment Length field
  429. contains the total length of the datagram.]
  430.  
  431. The More Fragments flag of CLNP is semantically and syntactically
  432. the same as the More Fragments flag of IP; a value of one (1)
  433. indicates that more segments/fragments are forthcoming; a value
  434. of zero (0) indicates that the last octet of the original packet
  435. is present in this segment.
  436.  
  437. The Error Report (ER) flag is used to suppress the generation of
  438. an error message by a host/router that detects an error during
  439. the processing of a CLNP datagram; a value of one (1) indicates
  440. that the host that originated this datagram thinks error reports
  441. are useful, and would dearly love to receive one if a host/router
  442. finds it necessary to discard its datagram(s).
  443.  
  444. 4.6  Type field
  445.  
  446. The type field distinguishes data CLNP packets from Error Reports
  447. from Echo packets. The following values of the type field apply:
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465. IETF                               Page 8
  466. Internet Draft            CLNP for TUBA              July 2, 1993
  467.  
  468.  
  469.   0   1   2   3   4   5   6   7
  470. +---+---+---+---+---+---+---+---+
  471. | flags     | 1 | 1 | 1 | 0 | 0 |  => Encoding of Type = data packet
  472. +---+---+---+---+---+---+---+---+
  473. | flags     | 0 | 0 | 0 | 0 | 1 |  => Encoding of Type = error report
  474. +---+---+---+---+---+---+---+---+
  475. | flags     | 1 | 1 | 1 | 1 | 0 |  => Encoding of Type = echo request
  476. +---+---+---+---+---+---+---+---+
  477. | flags     | 1 | 1 | 1 | 1 | 1 |  => Encoding of Type = echo reply
  478. +---+---+---+---+---+---+---+---+
  479.  
  480.  
  481.  
  482. Error Report packets are described in Section 5.
  483.  
  484. Echo packets and their use are described in RFC 1139 [9].
  485.  
  486.  
  487.  
  488. 4.7  Fragment Length
  489.  
  490. Like the Total Length of the IP header, the Fragment length field
  491. contains the length in octets of the fragment (i.e., this
  492. datagram) including both header and data.
  493.  
  494. [Note: CLNP also has a Total Length field, that contains the
  495. length of the original datagram; i.e., the sum of the length of
  496. the CLNP header plus the length of the data submitted by the
  497. higher level protocol, e.g., TCP or UDP. See Section 4.12.]
  498.  
  499. 4.8  Checksum
  500.  
  501. A checksum is computed on the header only. It is verified at each
  502. host/router that processes the packet; if header fields are
  503. changed during processing (e.g., the Lifetime), the checksum is
  504. modified. If the checksum is not used, this field must be coded
  505. with a value of zero (0). See Appendix A for algorithms used in
  506. the computation and adjustment of the checksum. Readers are
  507. encouraged to see [10] for a description of an efficient
  508. implementation of the checksum algorithm.
  509.  
  510. 4.9  Addressing
  511.  
  512. General purpose CLNP implementations must handle NSAPA addresses
  513. of variable length up to 20 octets, as defined in ISO/IEC 8348
  514. [11]. TUBA implementations, especially routers, must accommodate
  515. these as well. Thus, for compatibility and interoperability with
  516. OSI use of CLNP, the initial octet of the Destination Address is
  517. assumed to be an Authority and Format Indicator, as defined in
  518. ISO/IEC 8348. NSAP addresses may be between 8 and 20 octets long
  519. (inclusive).
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531. IETF                               Page 9
  532. July 2, 1993             CLNP for TUBA             Internet Draft
  533.  
  534.  
  535. TUBA implementations must support both ANSI and GOSIP style
  536. addresses; these are described in RFC 1237 [12], and illustrated
  537. in Figure 4-2.  RFC 1237 describes the ANSI/GOSIP initial domain
  538. parts as well as the format and composition of the domain
  539. specific part. It is further recommended that TUBA
  540. implementations support the assignment of system identifiers for
  541. TUBA/CLNP hosts defined in [13] for the purposes of host address
  542. autoconfiguration as described in [14]. Additional considerations
  543. specific to the interpretation and encoding of the selector part
  544. are described in sections 4.9.2 and 4.9.4.
  545.  
  546.                _______________
  547.                |<--__IDP_-->_|___________________________________
  548.                |AFI_|__IDI___|___________<--_DSP_-->____________|
  549.                |_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_|
  550.         octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|
  551.  
  552.                     Figure 4-2 (a): GOSIP Version 2 NSAP structure.
  553.                ______________
  554.                |<--_IDP_-->_|_____________________________________
  555.                |AFI_|__IDI__|____________<--_DSP_-->_____________|
  556.                |_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_|
  557.         octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|
  558.  
  559.                      IDP   Initial Domain Part
  560.                      AFI   Authority and Format Identifier
  561.                      IDI   Initial Domain Identifier
  562.                      DSP   Domain Specific Part
  563.                      DFI   DSP Format Identifier
  564.                      ORG   Organization Name (numeric form)
  565.                      Rsvd  Reserved
  566.                      RD    Routing Domain Identifier
  567.                      Area  Area Identifier
  568.                      ID    System Identifier
  569.                      SEL   NSAP Selector
  570.  
  571.                  Figure 4-2 (b): ANSI NSAP address format for DCC=840
  572.  
  573. 4.9.1  _D_e_s_t_i_n_a_t_i_o_n__A_d_d_r_e_s_s__L_e_n_g_t_h__I_n_d_i_c_a_t_o_r
  574.  
  575. This field indicates the length, in octets, of the Destination
  576. Address.
  577.  
  578. 4.9.2  _D_e_s_t_i_n_a_t_i_o_n__A_d_d_r_e_s_s
  579.  
  580. This field contains an OSI NSAP address, as described in Section
  581. 4.9.
  582.  
  583. The final octet of the destination address must always contain
  584. the value of the PROTO field, as defined in IP.  The 8-bit PROTO
  585. field indicates the next level protocol used in the data portion
  586. of the CLNP datagram.  The values for various protocols are
  587. specified in "Assigned Numbers" [15]. For the PROTO field, the
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597. IETF                              Page 10
  598. Internet Draft            CLNP for TUBA              July 2, 1993
  599.  
  600.  
  601. value of zero (0) is reserved.
  602.  
  603. Tuba implementations that support TCP/UDP as well as OSI should
  604. use the protocol value (29) reserved for ISO transport protocol
  605. class 4.
  606.  
  607. 4.9.3  _S_o_u_r_c_e__A_d_d_r_e_s_s__L_e_n_g_t_h__I_n_d_i_c_a_t_o_r
  608.  
  609. This field indicates the length, in octets, of the Source
  610. Address.
  611.  
  612. 4.9.4  _S_o_u_r_c_e__A_d_d_r_e_s_s
  613.  
  614. This field contains an OSI NSAP address, as described in Section
  615. 4.9.
  616.  
  617. The final octet of the source address is reserved. It may be set
  618. to the protocol field value on transmission, and shall be ignored
  619. on reception (the value of zero must not be used).
  620.  
  621. 4.10  Data Unit Identifier
  622.  
  623. Like the Identification field of IP, this 16-bit field is used to
  624. distinguish segments of the same (original) packet for the
  625. purposes of reassembly.
  626.  
  627. 4.11  Fragment Offset
  628.  
  629. Like the Fragment Offset of IP, this 16-bit is used to identify
  630. the relative octet position of the data in this fragment with
  631. respect to the start of the data submitted to CLNP; i.e., it
  632. indicates where in the original datagram this fragment belongs.
  633.  
  634. 4.12  Total Length
  635.  
  636. The total length of the CLNP packet in octets is determined by
  637. the originator and placed in the Total Length field of the
  638. header. The Total Length field specifies the entire length of the
  639. original datagram, including both the header and data. This field
  640. must not be changed in any fragment of the original packet for
  641. the duration of the packet lifetime.
  642.  
  643. 4.13  Options
  644.  
  645. All CLNP options are "triplets" of the form <parameter code>,
  646. <parameter lenth>, and <parameter value>.  Both the parameter
  647. code and length fields are always one octet long; the length
  648. parameter value, in octets, is indicated in the parameter length
  649. field. The following options are defined for CLNP for TUBA.
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. IETF                              Page 11
  664. July 2, 1993             CLNP for TUBA             Internet Draft
  665.  
  666.  
  667. 4.13.1  _S_e_c_u_r_i_t_y
  668.  
  669. The value of the parameter code field is binary 1100 0101. The
  670. length field must be set to the length of a Basic (and Extended)
  671. Security IP option(s) as identified in RFC1108 [16], plus 1.
  672. Octet 1 of the security parameter value field -- the CLNP
  673. Security Format Code -- is set to a binary value 0100 0000,
  674. indicating that the remaining octets of the security field
  675. contain either the Basic or Basic and Extended Security options
  676. as identified in RFC 1108. This encoding points to the
  677. administration of the source address (e.g., ISOC) as the
  678. administration of the security option; it is thus distinguished
  679. from the globally unique format whose definition is reserved for
  680. OSI use.  Implementations must examine the PROTO field in the
  681. source address; if the value of PROTO indicates the CLNP client
  682. is TCP or UDP, the security option described in RFC1108 is used.
  683.  
  684. The formats of the Security option, encoded as a CLNP option, is
  685. as follows. The CLNP option will be used to convey the Basic and
  686. Extended Security options as sub-options; i.e., the exact
  687. encoding of the Basic/Extended Security IP Option is carried in a
  688. single CLNP Security Option, with the length of the CLNP Security
  689. option reflecting the sum of the lengths of the Basic and
  690. Extended Security IP Option.
  691.  
  692.  
  693. +--------+--------+--------+--------+--------+------//-----+---
  694. |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY|             |          ...
  695. +--------+--------+--------+--------+--------+------//-----+------
  696.  CLNP       CLNP     CLNP     BASIC   BASIC    BASIC
  697.  OPTION    OPTION   FORMAT  SECURITY  OPTION   OPTION
  698.  TYPE      LENGTH    CODE    TYPE     LENGTH   VALUE
  699.  (197)                       (130)
  700.  
  701.  
  702.       ---+------------+------------+----//-------+
  703.  ...     |  10000101  |  000LLLLL  |             |
  704.     -----+------------+------------+----//-------+
  705.             EXTENDED     EXTENDED    EXTENDED OPTION
  706.             OPTION       OPTION          VALUE
  707.            TYPE (133)    LENGTH
  708.  
  709.  
  710.  
  711. The syntax, semantics and  processing of the Basic and Extended
  712. IP Security Options are defined in RFC 1108.
  713.  
  714. 4.13.2  _T_y_p_e__o_f__S_e_r_v_i_c_e
  715.  
  716. The value of the parameter code field must be set to a value of
  717. binary 1100 0011 (the CLNP Quality of Service Option Code point).
  718. The length field must be set to the length of the type of service
  719. field as identified in RFC 1349, Type of Service in the Internet
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729. IETF                              Page 12
  730. Internet Draft            CLNP for TUBA              July 2, 1993
  731.  
  732.  
  733. Protocol Suite [17], plus 1 (i.e., the value is 2). Octet 1 of
  734. the type of service parameter field is set to a binary value 0100
  735. 0000, indicating that the remaining octet of the Type Of Service
  736. field is to be encoded as described in RFC 1349.  This encoding
  737. points to the administration of the source address (e.g., ISOC)
  738. as the administration of the CLNP QOS option; it is thus
  739. distinguished from the globally unique QOS format whose
  740. definition is reserved for OSI use.  Implementations must examine
  741. the PROTO field in the source address; if the value of PROTO
  742. indicates the CLNP client is TCP or UDP, the TOS described in
  743. RFC1349 is used.
  744.  
  745.  
  746. +-----------+----------+----------+----------+
  747. | 1100 0011 | 00000010 | 01000000 | PPPTTTT0 |
  748. +-----------+----------+----------+----------+
  749.  CLNP QOS     OPTION    QOS FORMAT  IP TOS
  750.  TYPE (195)   LENGTH       CODE      OCTET
  751.  
  752.  
  753. The Type of Service octet consists of three fields:
  754.  
  755.  
  756.    0     1     2     3     4     5     6     7
  757. +-----+-----+-----+-----+-----+-----+-----+-----+
  758. |   PRECEDENCE    |          TOS          | MBZ |
  759. +-----+-----+-----+-----+-----+-----+-----+-----+
  760.  
  761. The first field, labeled "PRECEDENCE" above, is intended to
  762. denote the importance or priority of the datagram. The second
  763. field, labeled "TOS" above, denotes how the network should make
  764. tradeoffs between throughput, delay, reliability, and cost. The
  765. last field must be zero ("MBZ").
  766.  
  767. The processing of the type of service option is defined in
  768. RFC1349. The rules for applying TOS in Error and Report messages
  769. should correspond to those applied to the corresponding ICMP
  770. messages; i.e., error messages must always be sent with the
  771. default TOS; request messages may have any correct TOS value, and
  772. replies must be sent with the same value in the TOS field as was
  773. used in the corresponding request message.
  774.  
  775. [Editor's Note: It has been suggested that the IP precedence map
  776. directly into a CLNP option, Priority. The  feature will be
  777. provided irrespective of whether precedence is encoded in the TOS
  778. or Priority option.]
  779.  
  780. 4.13.3  _P_a_d_d_i_n_g
  781.  
  782. The padding field is used to lengthen the packet header to a
  783. convenient size. The parameter code field must be set to a value
  784. of binary 1100 1100. The value of the  parameter length field is
  785. variable. The parameter value may contain any value.
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795. IETF                              Page 13
  796. July 2, 1993             CLNP for TUBA             Internet Draft
  797.  
  798.  
  799. +----------+----------+-----------+
  800. | 11001100 | LLLLLLLL | VVVV VVVV |
  801. +----------+----------+-----------+
  802.  
  803. 4.13.4  _S_o_u_r_c_e__R_o_u_t_i_n_g
  804.  
  805. Like the strict source route option of IP, the Complete Source
  806. Route option of CLNP is used to specify the exact and entire
  807. route an internet datagram must take. Similarly, the Partial
  808. Source Route option of CLNP provides the equivalent of the loose
  809. source route option of IP; i.e., a means for the source of an
  810. internet datagram to supply (some) routing information to be used
  811. by gateways in forwarding the internet datagram towards its
  812. destination.
  813.  
  814. The parameter code for Source Routing is binary 1100 1000. The
  815. length of the source routing parameter value is variable.
  816.  
  817. The first octet of the parameter value is a type code, indicating
  818. Complete Source Routing (binary 0000 0001) or partial source
  819. routing (binary 0000 0000). The second octet identifies the
  820. offset of the next network entity title to be processed in the
  821. list, relative to the start of the parameter (i.e., a value of 3
  822. is used to identify the first address in the list). The third
  823. octet begins the list of network entity titles.
  824.  
  825. 4.13.5  _R_e_c_o_r_d__R_o_u_t_e
  826.  
  827. Like the IP record route option, the Record route option of CLNP
  828. is used to trace the route a CLNP datagram takes.
  829.  
  830. The parameter code for Record Route is binary 1100 1011. The
  831. length of the record route parameter value is variable.
  832.  
  833. The first octet of the parameter value is a type code, indicating
  834. Complete Source Route (0000 0001) Partial Recording of Route
  835. (0000 0000). The second octet identifies the offset where the
  836. next network entity title may be recorded (i.e., the end of the
  837. current list), relative to the start of the parameter (i.e., a
  838. value of 3 is used to identify the initial recording position).
  839. If recording of route has been terminated (I'll be back...), this
  840. octet has a value 255. The third octet begins the list of network
  841. entity titles.
  842.  
  843. 4.13.6  _T_i_m_e_s_t_a_m_p
  844.  
  845. [Editor's Note: There is no timestamp option in edition 1 of
  846. ISO/IEC 8473, but the option has been proposed and submitted to
  847. ISO/IEC JTC1/SC6.]
  848.  
  849. The parameter code value 1110 1110 is used to identify the
  850. Timestamp option; the syntax and semantics of Timestamp are
  851. identical to that defined in IP.
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861. IETF                              Page 14
  862. Internet Draft            CLNP for TUBA              July 2, 1993
  863.  
  864.  
  865. The Timestamp Option is defined in RFC 791. The CLNP parameter
  866. code 1110 1110 is used rather than the option type code 68 to
  867. identify the Timestamp option, and  the parameter value conveys
  868. the option length. Octet 1 of the Timestamp parameter value shall
  869. be encoded as the pointer (octet 3 of IP Timestamp); octet 2 of
  870. the parameter value shall be encoded as the overflow/format octet
  871. (octet 4 of IP Timestamp); the remaining octets shall be used to
  872. encode the timestamp list. The size is fixed by the source, and
  873. cannot be changed to accommodate additional timestamp
  874. information.
  875.  
  876.  
  877.         +--------+--------+--------+--------+
  878.         |11101110| length | pointer|oflw|flg|
  879.         +--------+--------+--------+--------+
  880.         |         network entity title      |
  881.         +--------+--------+--------+--------+
  882.         |             timestamp             |
  883.         +--------+--------+--------+--------+
  884.         |                 .                 |
  885.                           .
  886.  
  887.  
  888.  
  889. 5.  Error Reporting and Control Message Handling
  890.  
  891. CLNP and IP  differ in the way in which errors are reported to
  892. hosts. In IP environments, the Internet Control Message Protocol
  893. (ICMP, [7]) is used to return (error) messages to hosts that
  894. originate packets that cannot be processed. ICMP messages are
  895. transmitted as user data in IP datagrams. Unreachable
  896. destinations, incorrectly composed IP datagram headers, IP
  897. datagram discards due to congestion, and lifetime/reassembly time
  898. exceeded are reported; the complete internet header that caused
  899. the error plus 8 octets of the segment contained in that IP
  900. datagram are returned to the sender as part of the ICMP error
  901. message. For certain errors, e.g., incorrectly composed IP
  902. datagram headers, the specific octet which caused the problem is
  903. identified.
  904.  
  905. In CLNP environments, an unique message type, the Error Report
  906. type, is used in the network layer protocol header to distinguish
  907. Error Reports from CLNP datagrams. CLNP Error Reports are
  908. generated on detection of the same types of errors as with ICMP.
  909. Like ICMP error messages, the complete CLNP header that caused
  910. the error is returned to the sender in the data portion of the
  911. Error Report. Implementations should return at least 8 octets of
  912. the datagram contained in the CLNP datagram to the sender of the
  913. original CLNP datagram. Here too, for certain errors, the
  914. specific octet which caused the problem is identified
  915.  
  916. A summary of the contents of the CLNP Error Report, as it is
  917. proposed for use in TUBA environments, is illustrated in Figure
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927. IETF                              Page 15
  928. July 2, 1993             CLNP for TUBA             Internet Draft
  929.  
  930.  
  931. 5-1:
  932.  
  933.  
  934.     0                   1                   2                   3
  935.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  936.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  937.    |        ........Data Link Header........       | NLP ID        |
  938.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  939.    |Header Length  |     Version   | Lifetime (TTL)| 000 | Type=ER |
  940.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  941.    |  TOTAL Length of Error Report |           Checksum            |
  942.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  943.    | Dest Addr Len |               Destination Address...          |
  944.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  945.    |               ... Destination Address...                      |
  946.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  947.    |               ... Destination Address...                      |
  948.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  949.    |               ... Destination Address...                      |
  950.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  951.    |               ... Destination Address...                      |
  952.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  953.    | PROTO field   | Src  Addr Len |  Source  Address...           |
  954.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  955.    |               ... Source Address...                           |
  956.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  957.    |               ... Source Address...                           |
  958.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  959.    |               ... Source Address...                           |
  960.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  961.    |               ... Source Address...                           |
  962.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  963.    |       ... Source Address      | Reason for Discard (type/len) |
  964.    |                               |   1100 0001   | 0000 0010     |
  965.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  966.    |     Reason for Discard        |    Options...                 |
  967.    |   code        |   pointer     |                               |
  968.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  969.    |                           Options                             |
  970.    :                                                               :
  971.    |                                                               |
  972.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  973.  
  974.           Note that each tick mark represents one bit position.
  975.  
  976.  
  977.                         Figure 5-1. Error Report Format
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993. IETF                              Page 16
  994. Internet Draft            CLNP for TUBA              July 2, 1993
  995.  
  996.  
  997. 5.1  Rules for processing an Error Report
  998.  
  999. The following is a summary of the rules for processing an Error
  1000. Report:
  1001.  
  1002.    o+ An Error Report is not generated to report a problem
  1003.      encountered while processing an Error Report.
  1004.  
  1005.    o+ Error Reports may not be fragmented (hence, the
  1006.      fragmentation part is absent).
  1007.  
  1008.    o+ The Reason for Discard Code field is populated with one of
  1009.      the values from Table 5-1.
  1010.  
  1011.    o+ The Pointer field is populated with number of the first
  1012.      octet of the field that caused the Error Report to be
  1013.      generated. If it is not possible to identify the offending
  1014.      octet, this field must be zeroed.
  1015.  
  1016.    o+ If the Priority or Type of Service option is present in the
  1017.      errored datagram, the Error Report shall specify the same
  1018.      option, using the value specified in the original datagram.
  1019.  
  1020.    o+ If the Security option is present in the errored datagram,
  1021.      the Error Report shall specify the same option, using the
  1022.      value specified in the original datagram; if the Security
  1023.      option is not supported, no Error Report is to be generated
  1024.      (i.e., "silently discard" the received datagram).
  1025.  
  1026.    o+ If the Complete Source Route option is specified in the
  1027.      errored datagram, the Error Report must compose a reverse of
  1028.      that route, and return the datagram along the same path.
  1029.  
  1030. 5.2  Comparison of ICMP and CLNP Error Messages
  1031.  
  1032. Table 5-1 provides a loose comparison of ICMP message types and
  1033. codes to CLNP Error Type Codes (values in Internet ASCII):
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059. IETF                              Page 17
  1060. July 2, 1993             CLNP for TUBA             Internet Draft
  1061.  
  1062.  
  1063. CLNP Error Type  Codes            | ICMP Message           (Type, Code)
  1064. ----------------------------------|------------------------------------
  1065. Reason not specified          (0) | Parameter Problem           (12, 0)
  1066. Protocol Procedure Error      (1) | Parameter Problem           (12, 0)
  1067. Incorrect Checksum            (2) | Parameter Problem           (12, 0)
  1068. PDU Discarded--Congestion     (3) | Source Quench                (4, 0)
  1069. Header Syntax Error           (4) | Parameter problem           (12, 0)
  1070. Need to Fragment could not    (5) | Frag needed, DF set          (3, 4)
  1071. Incomplete PDU received       (6) | Parameter Problem           (12, 0)
  1072. Duplicate Option              (7) | Parameter Problem           (12, 0)
  1073. Destination Unreachable     (128) | Dest Unreachable,Net unknown (3, 0)
  1074. Destination Unknown         (129) | Dest Unreachable,host unknown(3, 1)
  1075. Source Routing Error        (144) | Source Route failed          (3, 5)
  1076. Source Route Syntax Error   (145) | Source Route failed          (3, 5)
  1077. Unknown Address in Src Route(146) | Source Route failed          (3, 5)
  1078. Path not acceptable         (147) | Source Route failed          (3, 5)
  1079. Lifetime expired            (160) | TTL exceeded                (11, 0)
  1080. Reassembly Lifetime Expired (161) | Reassembly time exceeded    (11, 1)
  1081. Unsupported Option          (176) | Parameter Problem           (12, 0)
  1082. Unsupported Protocol Version(177) | Parameter problem           (12, 0)
  1083. Unsupported Security Option (178) | Parameter problem           (12, 0)
  1084. Unsupported Src Rte Option  (179) | Parameter problem           (12, 0)
  1085. Unsupported Rcrd Rte        (180) | Parameter problem           (12, 0)
  1086. Reassembly interference     (192) | Reassembly time exceeded    (11,1)
  1087.  
  1088.  
  1089. Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
  1090.  
  1091. Note 1: The current use of the source quench is only
  1092.         when packets are discarded, and thus the current use
  1093.         meaning is the same; if a future RFC describes a more
  1094.         robust treatment of the source quench, the applicability
  1095.         of this CLNP Error Report Type should be reconsidered.
  1096.  
  1097. Note 2: There are no corresponding CLNP Error Report Codes for the
  1098.         following ICMP error message types:
  1099.         - Protocol Unreachable  (3, 2)
  1100.         - Port Unreachable      (3, 3)
  1101.         [ED. There are error code points available in the ER type
  1102.              code block that can be used to identify these message types.]
  1103.  
  1104.  
  1105.  
  1106. 6.  Pseudo-Header Considerations
  1107.  
  1108. A checksum is computed on UDP and TCP segments to verify the
  1109. integrity of the UDP/TCP segment. To further verify that the
  1110. UDP/TCP segment has arrived at its correct destination, a
  1111. pseudo-header consisting of information used in the delivery of
  1112. the UDP/TCP segment is composed and included in the checksum
  1113. computation.
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125. IETF                              Page 18
  1126. Internet Draft            CLNP for TUBA              July 2, 1993
  1127.  
  1128.  
  1129. To compute the checksum on a UDP or TCP segment prior to
  1130. transmission, implementations must compose a pseudo-header to the
  1131. UDP/TCP segment consisting of the following information that will
  1132. be used when composing the CLNP datagram:
  1133.  
  1134.    o+ Destination Address Length Indicator
  1135.  
  1136.    o+ Destination Address (including PROTO field)
  1137.  
  1138.    o+ Source Address Length Indicator
  1139.  
  1140.    o+ Source Address (including Reserved field)
  1141.  
  1142.    o+ A two-octet encoding of the Protocol value
  1143.  
  1144.    o+ TCP/UDP segment length
  1145.  
  1146. Figure 5-1 illustrates the resulting pseudo-header when both
  1147. source and destination addresses are maximum length.
  1148.  
  1149.  
  1150.     0                   1                   2                   3
  1151.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1152.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1153.    | Dest Addr Len |               Destination Address...          |
  1154.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1155.    |               ... Destination Address...                      |
  1156.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1157.    |               ... Destination Address...                      |
  1158.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1159.    |               ... Destination Address...                      |
  1160.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1161.    |               ... Destination Address...                      |
  1162.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1163.    |    (PROTO)    | Src  Addr Len |  Source  Address...           |
  1164.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1165.    |               ... Source Address...                           |
  1166.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1167.    |               ... Source Address...                           |
  1168.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1169.    |               ... Source Address...                           |
  1170.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1171.    |               ... Source Address...                           |
  1172.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1173.    | ...           | (Reserved)    |    Protocol                   |
  1174.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1175.    |   UDP/TCP segment length      |
  1176.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1177.  
  1178. Figure 5-1. Pseudo-header
  1179.  
  1180. If the length of the {source address length indicator + source
  1181. address + destination address indicator + destination address }
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191. IETF                              Page 19
  1192. July 2, 1993             CLNP for TUBA             Internet Draft
  1193.  
  1194.  
  1195. is not an integral number of octets, a trailing 0x0 nibble is
  1196. padded. If GOSIP compliant NSAP addresses are used, this never
  1197. happens (this is known as the Farinacci uncertainty principle).
  1198. The last byte in the Destination Address has the value 0x06 for
  1199. TCP and 0x11 for UDP, and that the Protocol field is encoded
  1200. 0x0006 for TCP and 0x0011 for UDP If needed, an octet of zero is
  1201. added to the end of the UDP/TCP segment to pad the datagram to a
  1202. length that is a multiple of 16 bits. In all other respects,
  1203. rules for computing the checksum are consistent with RFC 793 and
  1204. RFC 768.
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257. IETF                              Page 20
  1258. Internet Draft            CLNP for TUBA              July 2, 1993
  1259.  
  1260.  
  1261. 7.  REFERENCES
  1262.  
  1263. [1]     ISO/IEC 8473-1992. International Standards Organization -- Data
  1264.         Communications -- Protocol for Providing the Connectionless-mode
  1265.         Network Service, Edition 2.
  1266.  
  1267. [2]     Callon, R., TCP/UDP over Bigger Addresses (TUBA), Request for
  1268.         Comments 1347, Network Information Center, SRI
  1269.         International, Menlo Park, CA, May 1992.
  1270.  
  1271. [3]     Postel, J., Transmission Control Protocol (TCP). Request for
  1272.         Comments 793, Network Information Center, SRI
  1273.         International, Menlo Park, CA, 1981 September.
  1274.  
  1275. [4]     Postel, J., User Datagram Protocol (UDP). Request for Comments 768,
  1276.         Network Information Center, SRI International, Menlo Park, CA.
  1277.  
  1278. [5]     Postel, J., Internet Protocol (IP). Request for Comments 791,
  1279.         Network Information Center, SRI International, Menlo Park,
  1280.         CA, 1981 September.
  1281.  
  1282. [6]     Chapin, L., ISO DIS 8473, Protocol for Providing the
  1283.         Connectionless Network Service. Request for Comments 994,
  1284.         Network Information Center, SRI International, Menlo Park, CA,
  1285.         1986 March.
  1286.  
  1287. [7]     Postel, J.  Internet Control Message Protocol. Request for
  1288.         Comments 792, Network Information Center, SRI International,
  1289.         Menlo Park, CA  1981 September.
  1290.  
  1291. [8]     Braden, R.,ed.  Requirements for Internet hosts - communication layers
  1292.         Request for Comments 1122. Network Information Center, SRI
  1293.         International, Menlo Park, CA, 1989 October.
  1294.  
  1295. [9]     Hagens, R. and C. Wittbrodt, CLNP Ping, Request for Comments
  1296.         1139, Network Information Center, SRI International, Menlo
  1297.         Park, CA. 1993 May.
  1298.  
  1299. [10]    Sklower, K., <checksum implemenation article from CCR>
  1300.  
  1301. [11]    ISO/IEC 8348-1992. International Standards Organization--Data
  1302.         Communications--OSI Network Layer Service and Addressing.
  1303.  
  1304. [12]    Callon, R.,  NSAPA Guidelines for the Internet,
  1305.         Request for Comments RFC 1237, Network Information Center, SRI
  1306.         International, Menlo Park, CA.
  1307.  
  1308. [13]    Piscitello, D., Assignment of System Identifiers for TUBA/CLNP
  1309.         hosts, Internet-drafts (draft-tuba-sysids-01.txt).
  1310.  
  1311. [14]    ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data
  1312.         Communications -- End System to Intermediate System Routeing
  1313.         Exchange Protocol for use in conjunction with the protocol for
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323. IETF                              Page 21
  1324. July 2, 1993             CLNP for TUBA             Internet Draft
  1325.  
  1326.  
  1327.         providing the connectionless-mode network service -- Amendment 1:
  1328.         Dynamic Discovery of OSI NSAP Addresses by End Systems.
  1329.  
  1330. [15]    Reynolds, J., and J. Postel, Assigned Numbers.
  1331.         Request for Comments 1340, Network Information Center, SRI
  1332.         International, Menlo Park, CA. 1992 July.
  1333.  
  1334. [16]    Kent, S., Security Option for IP,
  1335.         Request for Comments 1108, Network Information Center, SRI
  1336.         International, Menlo Park, CA.
  1337.  
  1338. [17]    Almquist, P., Type of Service in the Internet
  1339.         Protocol Suite. Request for Comments 1349, Network Information
  1340.         Center, SRI International, Menlo Park, CA.
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389. IETF                              Page 22
  1390. Internet Draft            CLNP for TUBA              July 2, 1993
  1391.  
  1392.  
  1393. Appendix A. Checksum Algorithms (from ISO/IEC 8473)
  1394.  
  1395.  
  1396.  
  1397. Symbols used in algorithms:
  1398.         c0, c1          variables used in the algorithms
  1399.         i               position of octet in header (first
  1400.                         octet is i=1)
  1401.         Bi              value of octet i in the header
  1402.         n               position of first octet of checksum (n=8)
  1403.         L               Length of header in octets
  1404.         X               Value of octet one of the checksum parameter
  1405.         Y               Value of octet two of the checksum parameter
  1406.  
  1407. Addition is performed in one of the two following modes:
  1408.  
  1409.    o+ modulo 255 arithmetic;
  1410.  
  1411.    o+ eight-bit one's complement arithmetic;
  1412.  
  1413. The algorithm for Generating the Checksum Parameter Value is as
  1414. follows:
  1415.  
  1416.   A.  Construct the complete header with the value of the
  1417.       checksum parameter field set to zero; i.e., c0 <- c1 <- 0;
  1418.  
  1419.   B.  Process each octet of the header sequentially from i=1 to L
  1420.       by:
  1421.  
  1422.          o+ c0 <- c0 + Bi
  1423.  
  1424.          o+ c1 <- c1 + c0
  1425.  
  1426.   C.  Calculate X, Y as follows:
  1427.  
  1428.          o+ X <- (L - 8)(c0 - c1) modulo 255
  1429.  
  1430.          o+ Y <- (L - 7)(-C0) + c1
  1431.  
  1432.   D.  If X = 0, then X <- 255
  1433.  
  1434.   E.  If Y = 0, then Y <- 255
  1435.  
  1436.   F.  place the values of X and Y in octets 8 and 9 of the
  1437.       header, respectively
  1438.  
  1439. The algorithm for checking the value of the checksum parameter is
  1440. as follows:
  1441.  
  1442.   A.  If octets 8 and 9 of the header both contain zero, then the
  1443.       checksum calculation has succeeded; else if either but not
  1444.       both of these octets contains the value zero then the
  1445.       checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455. IETF                              Page 23
  1456. July 2, 1993             CLNP for TUBA             Internet Draft
  1457.  
  1458.  
  1459.   B.  Process each octet of the header sequentially from i = 1 to
  1460.       L by:
  1461.  
  1462.          o+ c0 <- c0 + Bi
  1463.  
  1464.          o+ c1 <- c1 + c0
  1465.  
  1466.   C.  When all the octets have been processed, if c0 = c1 = 0,
  1467.       then the checksum calculation has succeeded, else it has
  1468.       failed.
  1469.  
  1470. There is a separate algorithm to adjust the checksum parameter
  1471. value when a octet has been modified (such as the TTL). Suppose
  1472. the value in octet k is changed by Z = newvalue - oldvalue. If X
  1473. and Y denote the checksum values held in octets n and n+1
  1474. respectively, then adjust X and Y as follows:
  1475.  
  1476. If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then
  1477. the checksum is incorrect, else:
  1478.  
  1479. X <- (k - n - 1)Z + X   modulo 255
  1480.  
  1481. Y <- (n - k)Z + Y       modulo 255
  1482.  
  1483. If X = 0, then X <- 255; if Y = 0, then Y <- 255.
  1484.  
  1485. In the example, n = 89; if the octet altered is the TTL (octet
  1486. 4), then k = 4. For the case where the lifetime is decreased by
  1487. one unit (Z = -1), the assignment statements for the new values
  1488. of X and Y in the immediately preceeding algorithm simplify to:
  1489.  
  1490. X <- X + 5      Modulo 255
  1491.  
  1492. Y <- Y - 4      Modulo 255
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.